前言

在我準備 CKA 的過程中，常常會遇到一些看似「基本」卻其實隱藏設計哲學的問題。最近學到 Kubernetes 的授權（Authorization）機制時，我就有一個疑問：

👉 為什麼 kube-apiserver 允許設定多種 authorization mode，而且是「鏈式檢查」？
難道只用 RBAC 不就夠了嗎？

帶著這個疑問，我仔細研究了一下，發現這正是 Kubernetes 安全設計中一個很有趣的地方。

1. Kubernetes API Server 的請求流程

一個請求進到 API server 之後，大致會經過三個步驟：

1. Authentication：驗證身份
   → 確定這個 request 是誰發來的（憑證、Token、OIDC 等）。

2. Authorization：授權檢查
   → 判斷這個身份是否有權限執行該動作。
   這裡就會進入我們今天要講的 多種模式。

3. Admission Control：最後的管控
   → 檢查更細緻的規則，例如 ResourceQuota、PodSecurity、Mutating/Validating Webhook 等。

也就是說 Authentication 是「你是誰」，而 Authorization 是「你能做什麼」。

2. Kubernetes 支援的 Authorization Modes

Kubernetes 提供了數種授權模式，可以同時啟用，並由 API server 依照順序逐一檢查。常見的有：

• Node：專門給 kubelet（節點代理程式）使用。
• RBAC（Role-Based Access Control）：最常用的模式，針對使用者/群組/ServiceAccount 配置權限。
• ABAC（Attribute-Based Access Control）：早期的 JSON 規則式存取控制，現在已經較少使用。
• Webhook：把授權判斷丟給外部系統（例如 LDAP、SSO 或企業自建邏輯）。

啟用的方式如下：

--authorization-mode=Node,RBAC,Webhook

這表示 API server 會依序檢查 Node → RBAC → Webhook，直到有一個授權通過或全部拒絕。

3. 為什麼需要「鏈式授權」？

一開始我也納悶，為什麼不統一用 RBAC 就好？
仔細研究後發現，每一種模式其實是為了不同的需求存在的：

a. 系統元件的特殊需求

• Node Mode：只針對 kubelet 的請求，例如：
  • kubelet 下載自己應該跑的 Pod 規格。
  • kubelet 讀取 Pod 需要的 Secret / ConfigMap。
  • kubelet 更新自己的 Node 狀態。
• 如果這些都交給 RBAC，就得為每個 node 建立繁瑣的 RoleBinding，隨著節點彈性擴縮會非常痛苦。

b. 人類使用者與系統帳號

• RBAC 是集群管理員、開發者、CI/CD pipeline 最常用的授權機制。
• 提供細緻的權限分配，例如「user A 可以讀 namespace X 的 Pod，但不能刪」。

c. 外部或既有系統

• ABAC：早期已有 JSON 規則的公司可直接沿用。
• Webhook：方便整合企業內部的權限系統，符合特定合規需求。

d. 彈性的 fallback 機制

• 不同的請求來源可以由不同模式快速處理：
  • kubelet → Node Mode
  • 開發者 → RBAC
  • 特殊請求 → Webhook

4. 實際範例：Node Mode

Node Mode 是一個很好理解「為什麼要多模式」的例子。

範例 1：Kubelet 抓取 Pod 規格

當 pod 被排程到 node01 時：

1. kubelet 向 API server 請求「給我這個 Pod 的定義」。
2. API server 檢查：
   • request 是否來自 system:node:node01
   • pod 是否真的被分配到 node01
3. 符合就允許。

範例 2：讀取 Secret

假設 Pod 要掛載資料庫密碼，kubelet 需要抓取該 Secret。

• Node Mode 只允許 node01 抓取該 pod 對應的 Secret。
• 無法跨 namespace 或跨 node 存取其他 Secret → 避免資料外洩。

範例 3：更新 Node 狀態

• kubelet 定期更新自己的 Node 物件（Ready 狀態、資源使用量）。
• Node Mode 允許更新自己的 Node，但不能動其他 Node。

👉 如果只靠 RBAC，這些權限要手動為每個 node 建立，非常麻煩。Node Mode 內建的邏輯讓一切「開箱即用」。

5. 為什麼不只用一套統一系統？

Kubernetes 的設計哲學是 彈性 + 向後相容：

• 早期用 ABAC 的人，可以繼續用。
• 新使用者主要用 RBAC。
• 需要客製化的企業，用 Webhook。
• Kubelet 的情境太特殊，所以硬寫進 Node Mode。

這樣的設計，讓 Kubernetes 在不同場景下都能運作，而不需要強迫大家遷就單一模式。

6. 請求流程圖

最後用一張圖來說明整個流程會更直觀：

7. 總結

• Authorization Mode 可以鏈式檢查，是因為 Kubernetes 要兼顧不同角色的需求：
  • Node Mode → kubelet 系統元件
  • RBAC → 人類使用者與自動化帳號
  • Webhook/ABAC → 外部或特殊需求
• 這樣的設計，兼顧了 彈性、相容性與安全性。
• 對於準備 CKA 的人來說，可以把它想成一個 多層授權流水線：誰來、要做什麼、由誰來判斷。

✍️ 今天的心得就是：Kubernetes 授權不是只有 RBAC，Node、Webhook 等模式都有其存在價值。理解這些差異，可以幫助我們在考試或實務中更快定位問題，也能更靈活地設計安全策略。